Проект

10. Анализ пользовательского поведения в мобильном приложении

Описание проекта

Вы работаете в стартапе, который продаёт продукты питания. Нужно разобраться, как ведут себя пользователи вашего мобильного приложения.

Изучите воронку продаж. Узнайте, как пользователи доходят до покупки. Сколько пользователей доходит до покупки, а сколько — «застревает» на предыдущих шагах? На каких именно?

После этого исследуйте результаты A/A/B-эксперимента. Дизайнеры захотели поменять шрифты во всём приложении, а менеджеры испугались, что пользователям будет непривычно. Договорились принять решение по результатам A/A/B-теста. Пользователей разбили на 3 группы: 2 контрольные со старыми шрифтами и одну экспериментальную — с новыми. Выясните, какой шрифт лучше. Создание двух групп A вместо одной имеет определённые преимущества. Если две контрольные группы окажутся равны, вы можете быть уверены в точности проведенного тестирования. Если же между значениями A и A будут существенные различия, это поможет обнаружить факторы, которые привели к искажению результатов. Сравнение контрольных групп также помогает понять, сколько времени и данных потребуется для дальнейших тестов.

В случае общей аналитики и A/A/B-эксперимента работайте с одними и теми же данными. В реальных проектах всегда идут эксперименты. Аналитики исследуют качество работы приложения по общим данным, не учитывая принадлежность пользователей к экспериментам.

Проведем исследовательский анализ данных и ответим на вопросы:

План работ

1. Открываем файл с данными и изучаем общую информацию
2. Предобработка данных
2.1 Сколько событий в логе: всего, уникальных, на пользователя?
2.2 За какой период у нас данные? выберем актуальный период, в котором данные полные
2.3 Оставим данные только за актуальный период и определим какова потеря данных.
2.4 Распределение событий и пользователей по группам
3. Изучим воронку событий
3.1. Распределение событий в логе, данные для построения воронки продаж(событий)
3.2. Построим столбчатую диаграмму распределение событий между этапами и воронку продаж (событий)
4. Изучим результаты эксперимента
4.1. Распределение пользователей по группам и по событиям
4.2. Функция для проверки наличия статистической разницы долей пользователей, совершивших событие
4.3. Проверка наличия статистической разницы долей пользователей, совершивших событие (А/А и А/В тесты)
4.3.1 Гипотеза: доли уникальных посетителей групп 246 и 247 (А/А тест), побывавших на этапе воронки, одинаковы
4.3.2 Гипотеза: доли уникальных посетителей групп 246 и 248 (А/В тест), побывавших на этапе воронки, одинаковы
4.3.3 Гипотеза: доли уникальных посетителей групп 247 и 248 (А/В тест), побывавших на этапе воронки, одинаковы
4.3.4 Гипотеза: доли уникальных посетителей групп 246+247 и 248 (А/В тест), побывавших на этапе воронки, одинаковы
5. Общий вывод

1. Открываем файл с данными и изучаем общую информацию

К плану работ

Откроем файл с данными и изучим общую информацию.
Подготовьте данные: Замените названия столбцов на удобные для вас; Проверьте пропуски и типы данных. Откорректируйте, если нужно; Добавьте столбец даты и времени, а также отдельный столбец дат;

Выводы

Изначально в таблице было 244126 строк(событий) и 4 столбца:

- EventName(event - в скобках новое название) - имя события (object)   
- DeviceIDHash(userid) - ID пользователя  (int64)  
- EventTimestamp(datetime) - дата и время события (int64)   
- ExpId(group) - название группы  (int64)    

Переименовываем столбцы
Столбец дата и время события имеет числовой формат, меняем его на datetime64.
Проверяем пропуски в данных - их нет, полных дубликатов 413. Удаляем дубликаты.
Добавляем столбец даты события "eventdate", меняем формат столбца на date.
Также мы проверили - не попалили данные из одной группы в другую - нет, пересечения данных в группах нет
Проверка и подготовка данных завершена

2. Предобработка данных

К плану работ

Изучим следующие вопросы:
Сколько всего событий в логе?
Сколько всего пользователей в логе?
Сколько в среднем событий приходится на пользователя?
Данными за какой период вы располагаете? Найдем максимальную и минимальную дату. Построим гистограмму по дате и времени. Можно ли быть уверенным, что у вас одинаково полные данные за весь период? Технически в логи новых дней по некоторым пользователям могут «доезжать» события из прошлого — это может «перекашивать данные». Определим, с какого момента данные полные и отбросим более старые. Данными за какой период времени располагаем на самом деле?
Много ли событий и пользователей мы потеряли, отбросив старые данные?
Проверим, что у нас есть пользователи из всех трёх экспериментальных групп.

2.1 Сколько событий в логе: всего, уникальных, на пользователя?

К плану работ

2307 событий у одного пользователя и медиана 20 - это слишком большой разброс, явно есть выбросы. Построим гистограмму "среднее количество событий на пользователя"

Действительно, гистограмма имеет вид - распределение Пуасона начиная с 650 - это явно выбросы.

2.2 За какой период у нас данные? выберем актуальный период, в котором данные полные

К плану работ

На гистограмме явно видно что мобильным приложением стали активно пользоваться в промежуток времени между 2019-07-31 и 2019-08-01. Поэтому приблизим гистограмму выбрав именно этот временной промежуток.
Также на графике заметно что в июле событий практически нет, поэтому мы можем отсечь события до момента, который нам покажет укрупненная гистограмма. Построим ее.

по графикам видно что начало активного этапа - 2019-07-31 21:10:00. Это и примем за точку отсечения данных

2.3 Оставим данные только за актуальный период и определим какова потеря данных.

К плану работ

У нас есть пользователи из всех трёх экспериментальных групп - это видно из выведенной выше таблицы, см. выше.

Много ли событий и пользователей вы потеряли, отбросив старые данные?

Потери событий и пользователей менее 1% - не критичны для данных.

2.4 Распределение событий и пользователей по группам

К плану работ

Проверим, что у нас есть пользователи из всех трёх экспериментальных групп.

Вывод

Всего событий в логе: 243713
список уникальных событий:

среднее количество событий на пользователя: 32 медианное количество событий на пользователя: 20

Для выбора мреднего или медианного значения посмотрели описание таблицы - 2307 событий у одного пользователя(максимум) и медиана 20 - это слишком большой разброс, явно есть выбросы. Построим гистограмму "среднее количество событий на пользователя"

Действительно, гистограмма имеет вид - распределение Пуасона начиная с 650 - это явно выбросы. Поэтому принимаем медианное значение за среднее на пользователя.

В логе присутствуют данные с 2019-07-25 04:43:36 по 2019-08-07 21:15:17

Перестроив гистограмму укрупненно мы определили что начало активного этапа - 2019-07-31 21:10:00. Это и приняли за точку отсечения данных

Потери событий и пользователей после этого отсечения составляют менее 1% - не критичны для данных. Также мы проверили что есть пользователи из всех трёх экспериментальных групп - вывели верх таблицы на экран.

'количество событий по группам' 248 84868 246 79545 247 77288 Name: group, dtype: int64 'количество уникальных пользователей по группам' group 246 2484 247 2517 248 2537 Name: userid, dtype: int64

Несмотря на то что разница в событиях между группами достигает 7.5 тысяч(около 9%), уникальных пользователей в каждой группе одинаково разница около 2% - это меньше статичтической погрешности. Будем считать что данные по группам распределены равномерно.

3 Изучим воронку событий

К плану работ

Рассмотрим следующие вопросы:

3.1 Распределение событий в логе, данные для построения воронки продаж(событий)

К плану работ

В таблиу для построения воронки продаж мы добавили столбцы:

3.2 Построим столбчатую диаграмму распределение количества пользовательских действий в логе и воронку продаж (событий)

К плану работ

3.2 Построим столбчатую диаграмму распределение событий между этапами и воронку продаж (событий)

К плану работ

Выводы

В логе 5 событий:
MainScreenAppear - Главный экран - 117876
OffersScreenAppear - Экран каталога товаров - 42342
CartScreenAppear - Экран просмотра корзины - 42342
PaymentScreenSuccessful - Экран успешной оплаты - 33950
Tutorial - Экран руководство пользователя - 1010

События могут происходить следующим образом:

  1. Главный экран
  2. Экран руководство пользователя
  3. Экран каталога товаров
  4. Экран просмотра корзины
  5. Экран успешной оплаты
    Однако событие Экран руководства пользователя может быть пропущен и количество пользователей посещавших этот Экран крайне мало. Поэтому данными этого этапа Экран руководства пользователя мы не учитываем в дальнейшем.

Количество пользователей, которые совершили событие хотя бы раз:

Доля пользователей совершивших переход на следующий шаг воронки:

Поскольку целевое событие - это PaymentScreenSuccessful - экран успешной оплаты, а максимальное количество пользователей приходится на событие MainScreenAppear - Главный экран, логично предположить что воронка строится между этими двумя событиями.

Ни одно из событий не является обязательным и также какое-то событие пользователь может пропустить. Очевидно, что экран Tutorial - руководство пользователя пропускают чаще всего.
При выводе таблицы можно видеть что время экрана корзины и успешной оплаты бывает раньше чем просмотр экрана каталога и посещения главного экрана. Могу предположить что это случай, не первого визита пользователя в приложение. Скорее всего после просмотра отложенной корзины и ее оплаты - пользователь еще захотел что-либо выбрать. Кроме того среднее количество событий на одного пользователя в неделю(отсеченный нами период - первая неделя августа и данные нашего лога - медианное значение 20 событий) - это в среднем 3 события в день. Таким образом, при условии использования приложения ежедневно - минимум одно событие в среднем должно быть пропущено. Если рассуждать еще дальше - то скорее всего в каталог и корзину пользователь заходит при крупных покупках, в случае ежедневных мелких покупок - оплата может происходить без просмотра каталога - пользователь покупает новинки и спецпредложения которые видит на главном экране.

Больше всего потеря почти 40% происходит на 2-м шаге - открытие экрана каталога.

Почти 47% пользователей совершают покупку.

Расхождение в цифрах на воронке и в выводе связано с тем что в расчетах мы берем отфильтрованные данные по дате отсечения, а воронку строим по общему количеству зашедших на первый этап "Главный экран".

4 Изучим результаты эксперимента

К плану работ

Ответим на вопросы:

4.1 Распределение пользователей по группам и по событиям

К плану работ

Итак мы видим, что по группам уникальные пользователи распределены так:

4.2 Функция для проверки наличия статистической разницы долей пользователей, совершивших событие

К плану работ

Опеределим статистическую достоверность в контрольных группах по долям пользователей, совершивших событие.

напишем функцию, которая принимает в качестве аргументов 4 числа для z-теста пропорций (в теле функции не должно быть ни цикла, ни работы с датафреймом, только мат. вычисления для стат. теста.
Для корректности рассчетов применим поправку Бонферрони - разделим уровень статистической значимости на количество экспериментов(16 - 4 события на 4 теста А/А(246/247), А/В 246/248, 247/348 и 246+247/248).
Поскольку 5%/16=менее 1% - значит уровень статистической значимости для А/А эксперимента понижать не будем - он и так низкий.

4.3 Проверка гипотез о наличия статистической разницы долей пользователей, совершивших событие (А/А и А/В тесты)

К плану работ

4.3.1 Гипотеза: доли уникальных посетителей групп 246 и 247 (А/А тест), побывавших на этапе воронки, одинаковы

К плану работ

Примем
Нулевая гипотеза: доли уникальных посетителей групп 246 и 247 (А/А тест), побывавших на этапе воронки, одинаковы.

Альтенативная гипотеза: между долями уникальных посетителей, побывавших на этапе воронки, есть значимая разница.

Проверим ее для каждого из событий.

4.3.2 Гипотеза: доли уникальных посетителей групп 246 и 248 (А/В тест), побывавших на этапе воронки, одинаковы

К плану работ

Примем
Нулевая гипотеза: доли уникальных посетителей групп 246 и 248 экспериментальной (А/В тест), побывавших на этапе воронки, одинаковы.

Альтенативная гипотеза: между долями уникальных посетителей, побывавших на этапе воронки, есть значимая разница.**

Проверим ее для каждого из событий.

4.3.3 Гипотеза: доли уникальных посетителей групп 247 и 248 (А/В тест), побывавших на этапе воронки, одинаковы

К плану работ

Примем
Нулевая гипотеза: доли уникальных посетителей групп 247 и 248 экспериментальной (А/В тест), побывавших на этапе воронки, одинаковы.

Альтенативная гипотеза: между долями уникальных посетителей, побывавших на этапе воронки, есть значимая разница.**

Проверим ее для каждого из событий.

4.3.4 Гипотеза: доли уникальных посетителей групп 246+247 и 248 (А/В тест), побывавших на этапе воронки, одинаковы

К плану работ

Примем
Нулевая гипотеза: доли уникальных посетителей групп 246+247 и 248 экспериментальной (А/В тест), побывавших на этапе воронки, одинаковы.

Альтенативная гипотеза: между долями уникальных посетителей, побывавших на этапе воронки, есть значимая разница.**

Проверим ее для каждого из событий.

Значимой разницы во всех тестах между группами не выявлено

Выводы

Ни один из экспериментов не опроверг нулевую гипотезу о равности долей тестируемых групп включая экспериментальную 248. Стало быть изменение шрифтов выбранное дизайнером не повлияет на работу приложения интернет магазина продуктов.
Поскольку максимальное снижение количества пользователей происходит на 2-м этапе(событие - Экран каталога) я бы на месте маркетолога этой компании обратила внимание на такие характеристики:

  1. глубину скроллинга страниц пользователем
  2. время проведенное пользователем на сайте
  3. поло-возрастной диапазон самых активных покупателей
  4. категории товаров, которые дают максимальное пребывание на сайте и большие чеки
    Кроме того есть рекомендации по дизайну главного экрана приложения - как гипотезы для проверки:
  5. комплексные предложения категорий продуктов на главном экране - например "халяльная продукция", "кашерная продукция", "здоровое питание", которые позволят пользователю "провалиться" на второй экран
  6. предложила бы увеличить размер ценников "цена от" и сделать их контрастными и по центру главной страницы
  7. Изменила бы положительные заголовки на главном экране на отрицательные - например "надоело есть жирную и вредную еду?", "не можете найти свежие овощи?"

5 Общий вывод

К плану работ

В ходе анализа и эксперементов было сделано и выявлено:

Загрузка данных их проверка и подготовка к работе

Изначально в таблице было 244126 строк(событий) и 4 столбца:

Изучение и проверка данных

В процессе изучения данных выяснилось что всего событий в логе: 243713
список уникальных событий:

всего уникальных пользователей в логе 7551

Так как в данных есть выбросы, которые показала гистограмма - мы выбрали для изучения не среднее а медианное количество событий на пользователя: 20

В логе присутствуют данные с 2019-07-25 04:43:36 по 2019-08-07 21:15:17

Перестроив гистограмму укрупненно мы определили что начало активного этапа - 2019-07-31 21:10:00. Это и приняли за точку отсечения данных

Потери событий и пользователей после этого отсечения составляют менее 1% - не критичны для данных. Также мы проверили что есть пользователи из всех трёх экспериментальных групп - вывели верх таблицы на экран.

'количество уникальных пользователей по группам' group 246 2484 247 2517 248 2537

Снижение Уникальных пользователей в каждой группе одинаково разница около 2% - это меньше статичтической погрешности. Будем считать что данные по группам распределены равномерно.

Изучение воронки событий

В логе 5 событий:
MainScreenAppear - Главный экран - 117876
OffersScreenAppear - Экран каталога товаров - 42342
CartScreenAppear - Экран просмотра корзины - 42342
PaymentScreenSuccessful - Экран успешной оплаты - 33950
Tutorial - Экран руководство пользователя - 1010

События могут происходить следующим образом:

  1. Главный экран
  2. Экран руководство пользователя
  3. Экран каталога товаров
  4. Экран просмотра корзины
  5. Экран успешной оплаты
    Однако событие Экран руководства пользователя может быть пропущен и количество пользователей посещавших этот Экран крайне мало. Поэтому данными этого этапа Экран руководства пользователя мы не учитываем в дальнейшем.

Количество пользователей, которые совершили событие хотя бы раз:

Доля пользователей совершивших переход на следующий шаг воронки:

Поскольку целевое событие - это PaymentScreenSuccessful - экран успешной оплаты, а максимальное количкство пользователей приходится на событие MainScreenAppear - Главный экран, логично предположить что воронка строится между этими двумя событиями.

Я согласна, что ни одно из событий не является обязательным и также какое-то событие пользователь может пропустить. Очевидно, что экран Tutorial - руководство пользователя пропускают чаще всего.
При выводе таблицы можно видеть что время экрана корзины и успешной оплаты бывает раньше чем просмотр экрана каталога и посещения главного экрана. Могу предположить что это случай, не первого визита пользователя в приложение. Скорее всего после просмотра отложенной корзины и ее оплаты - пользователь еще захотел что-либо выбрать. Кроме того среднее количество событий на одного пользователя в неделю(отсеченный нами период - первая неделя августа и данные нашего лога - медианное значение 20 событий) - это в среднем 3 события в день. Таким образом, при условии использования приложения ежедневно - минимум одно событие в среднем должно быть пропущено. Если рассуждать еще дальше - то скорее всего в каталог и корзину пользователь заходит при крупных покупках, в случае ежедневных мелких покупок - оплата может происходить без просмотра каталога - н покупает новинки и спецпредложения которые видит на главном экране.

Больше всего потеря почти 40% происходит на 2-м шаге - открытие экрана каталога.

Почти 47% пользователей совершают покупку.

Расхождение в цифрах на воронке и в выводе связано с тем что в расчетах мы берем отфильтрованные данные по дате отсечения, а воронку строим по общему количеству зашедших на первый этап Главный экран.

Изучение результатов эксперимента

Итак мы видим, что по группам уникальные пользователи распределены так:

Уровень статистической значимости в 10% был бы слишком велик так как в тесте не ожидаем изменений не менее чем 30% (в таком случае 10% погрешности измерений нас бы устроила). При уровне значимости 0.1 только одна из проверок покажет значимую разницу, между контрольной группой A0 и экспериментальной в доле перехода пользователей в корзину(CartScreenAppear), но эта разница будет не в пользу нашей экспериментальной группы. Но при уровне значимости 0.1 каждый десятый раз можно получать ложный результат, поэтому стоит применить изначально выбранный нами уровень значимости 0.05.

В результате всех и каждого A/A/B эксперемента значимой разницы между группами не выявлено. Поэтому можно утверждать, что на поведение пользователей изменение шрифта значимого эффекта не оказало. Тестирование можно назвать успешным - изменение шрифта не повлияло на поведение пользователей.

Ни один из экспериментов не опроверг нулевую гипотезу о равности долей тестируемых групп включая экспериментальную 248. Стало быть изменение шрифтов выбранное дизайнером не повлияет на работу приложения интернет магазина продуктов. Поскольку максимальное снижение количества пользователей происходит на 2-м этапе(событие - Экран каталога) я бы на месте маркетолога этой компании обратила внимание на такие характеристики:

Кроме того есть рекомендации по дизайну главного экрана приложения - как гипотезы для проверки: